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Motivation 


•  Failure  Modes  and  Effects  Analyses  (and  related  Criticality  Analyses) 
are  rigorous  and  comprehensive  reliability  and  safety  design 
evaluations 


-  Generally  required  either  by  industry  standards  or  Government  policies 

-  A  fundamental  element  of  defense  in  many  product  liability  lawsuits 


•  When  performed  manually,  FMEAs  are  usually  done  only  once  during 
the  detailed  design  phase  because  of  cost  and  schedule  constraints 

-  Labor  intensive 

-  Require  senior  level;  analysts 


If  automated,  FMEAs  would  have  significant  benefits 

-  Multiple  iterations  from  conceptual  to  detailed  design 

-  Enables  early  identification  of  potential  problems 

•  Single  points  of  failure 

•  Unanticipated  effects 

-  Facilitates  tradeoff  studies  and  evaluations  of  alternatives 


Failure  Modes  and  Effects  Analysis  (FMEA) 


•  Purpose 

-  To  determine  the  effect  of  hardware  and  software  failures  upon  the  system 
and  equipment  failures. 

•  Classify  effects  by  impact  on  mission  success  and  personnel/equipment 
safety. 

•  Identify  single  points  of  failure 


•  History 

-  First  defined  as  Military  Procedure  MIL-P-1629,  “ Procedures  for  Performing 
a  Failure  Mode,  Effects  and  Criticality  Analysis”,  November  1949. 

-  Further  developed  and  applied  by  NASA  in  the  1960’s  to  improve  and  verify 
reliability  of  space  program  hardware. 

-  Since  the  1980s,  a  standard  of  practice  in  a  wide  variety  of  industries 


•DoD:  MIL-STD-1629A 
•Industrial:  IEC  60812  (1985) 
•Aviation:  SAE  ARP  5580  (2001) 

•  Automotive:  SAE  J1739  (2002) 

•  Spacer^CSS-Q-30-02A 


FMEA  Methodology 


Conventional 


Define  Ground  Rules  and  Assumptions 
Levels  of  indenture 
Components  to  be  considered 
Failure  modes  by  component 
category 

Severity  Level  Definitions 
Rules  for  recovery  mechanisms 
and  compensating  provisions 
For  Each  Component 

Postulate  failure  and  failure  mode 
Identify  immediate  effect  of  failure 
Identify  next  higher  level  effects 
and  “end  effects” 

Identify  compensating  provisions 
Evaluate  severity  level  at  end 
effect 


Automated 


•  Ground  rules  and  assumptions 
defined  by  component  properties 

•  Components  and  failure  modes 
defined  in  models 

•  Effects  identified  through 
graph  tracing 


FMEA  Output 

In  Either  Worksheet  or  Tabular  Format. . . 


•  Identification;  Failure  Mode  identification. 

•  Item;  For  software,  a  process  in  its  context. 

•  Failure  Mode; 

-  Immediate  Effect: 

-  Intermediate  Effect:  Second  level  effect 

•  Operator 

•  External  networks 

•  Database 

•  Recovery 

-  End  Effect: 


•  System  Level  (e.g.,  Individual  satellites  or  the  constellation  through  TT&C  functions) 

•  Payload  performance 

•  Data  to  outside  users  through  terrestrial  interfaces 


•  Existing  Mitigations;  Any  existing  mitigations  present  in  the  architecture  or 
design  were  identified. 

•  Severity  level: 

-  Set  under  assumption  that  existing  mitigations  assumed  to  work 

•  Comments: 

-  Additional  comments  documenting  assumptions  and  uncertainties. 


Introduction  to  the  Architecture  Analysis 
&  Design  Language  (AADL) 

•  Society  of  Automotive  Engineers  (SAE)  Aerospace  Standard  AS5506 
(2004) 

-  Preceded  by  more  than  a  decade  of  development  under  the  DARPA  Meta- 
Id  program 

•  Provides  a  standardized  textual  and  graphical  notation  for  describing 
software  and  hardware  system  architectures  and  their  functional 
interfaces 

-  architectures  (using  standard  language). 

-  expected  program  behavior  (using  behavior  annex) 

-  Failure  and  recovery  behavior  (using  error  annex) 


AADL  vs.  other  OMG  Languages  for  Stochastic  Analysis 
of  Risk  and  Reliability 


•  Advantages 

-  Objects  directly  represent  real-time  system  hardware  and  software 

-  Standard  method  for  incorporation  of  quantitative  attributes 

•  Failure  and  Recovery  Probabilistic  Distributions 

•  Parameters  of  those  distributions 

•  Probabilities  and  rates  for  individual  transitions 

-  Standard  methods  for  representing  propagation  of  failures  across  multiple 
components 

•  Event  ports  for  failure  propagations 

•  Guards  to  enable  conditional  propagations  (important  for  abstractions 
and  reuse) 

•  Drawbacks 

-  No  commercial  quality  tools 

•  Public  domain  tools  are  available  and  usable  - 


AADL  Components  (graphical  representation) 


/ 

7 

Processor 

/ 

Device 


-  text  and  xml  representations  also  defined 
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AADL  Error  Model  Annex 


•  AADL  annex  that  supports  stochastic  analysis 

•  Defines  error  model 

-  State  transition  diagram  that  represents  normal  and  failed  states 

-  Error  models  can  be  associated  with  hardware  components,  software 
components,  connections,  and  “ system ”  (composite)  components 

•  Error  model  consists  of 

-  State  definitions 

-  Propagations  from  and  to  other  components 

-  Probability  distribution  and  parameter  definitions 

-  Allowed  state  transitions  and  probabilities 


Enabling  Features  of  AADL 


•  Standard  representation  of  architecture  and  error  models 

•  Representation  of  failure  propagation  through  system 
components 

-  Event  Ports 

-  Guards 

-  Propagations 

•  Error  Model  properties 

-  Working  status  of  states 

-  Descriptive  information  for  initial  states,  effects  (subsequent 
states),  and  failure  modes  (transitions) 

-  Initial  states 

-  Terminal  States 


AADL  Error  Model  Example 


error  model  example 
features 

ErrorFree:  initial  error  state; 

Failed:  error  state; 

Fail:  error  event  {Occurrence  =>  poisson  lambda}; 

Repair:  error  event  {Occurrence  =>  poisson  mu}; 

Failvisible:  in  out  error  propagation  {Occurrence  =>  fixed  p}; 
end  example; 


error  model  implementation  example. general 
transitions 

ErrorFree-[Fail]->Failed;  . • 

Failed-[Repairl->ErrorFree;  . * 

ErrorFree-[in  Failvisible]->Failed; 

Failed-[out  Failvisible]->Failed;  . 

end  example. general; 


More  information:  Feiler  (2007) 


AADL  Tool  Set 


•  Eclipse  Development  Environment  (Ganymede)  and  Eclipse  Modeling 
Framework  (EMF) 

•  Component  plug-ins 

-  TopCASED  graphical  editor  to  create  AADL  architecture  diagrams  (SEI, 
Aerospace  modifications) 

-  Error  Model  Editor  graphical  editor  to  create  AADL  error  model  diagrams 
(The  Aerospace  Corporation  newly  developed) 

-  OS  ATE  AADL  generator  (SEI,  The  Aerospace  Corporation  modifications) 

-  ADAPT-M  Stochastic  Petri  net  to  MoBIUS  stochastic  analysis  network  tool 
((SEI/LAAS  Toulouse  and  The  Aerospace  Corporation) 

-  MoBIUS  Quantitative  Dependability  modeling  and  prediction  tool 
(University  of  Illinois,  Champaign  Urban  a) 

-  FMEAGEN  FMEA  Generator  (The  Aerospace  Corporation  newly 
developed) 


AADL  Modeling  Tool  Chain  Data  Flow 


Tool  Set  Screen  Shot 
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FMEA  Generation  Algorithm  Features 


•  Automatically  traces  from  all  working  states  to  failure  states 

-  Terminates  when  trace  detects  a  restoration  condition  or  a  failure 
condition 

•  Not  limited  to  only  3  levels  of  effects 

•  Checks  to  prevent  repeated  visits  to  same  states 

-  Ensures  termination 

-  Of  particular  importance  for  recoverable  systems 


Example:  Supplemental  Restraint  System 


Architectural 

Model 


Error  Models 


Accelerometer  Controlling  Airbag 


Generation 
of  FMEA 
from  Petri 
Net  of  Error 
Models 


Results:  Automatically  Generated  FMEA 
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Conclusions 


•  A  new  generation  tool  set  for  quantitative  stochastic  analysis  and 
qualitative  Failure  Modes  and  Effects  Analysis  (FMEAs)  for  space 
systems  is  under  development 

-  Based  on  use  of  the  Architecture  Analysis  and  Design  Language  (AADL) 

-  Graphically  oriented 

-  Modularized  with  reusable  components 


Automated  Generation  of  FMEA/CA  enables  multiple  iterations 
analyses  throughout  all  stages  of  the  design 

-  Allows  design  alternatives  to  be  evaluated 


•  Strategies  for  recovering  from  computing  disruptions 

•  Handling  failure  propagation  and  common  mode  failures 


-  Enables  safety  and  reliability  problems  to  be  identified  early 

•  Of  critical  importance  to  all  users  and  stakeholders 

•  Significant  economic  value  where  products  liability  is  an  issue  because 
of  conforming  and  exceeding  standard  of  care 


Acronyms 


ADAPT:  AADL  Architectural  models  to  stochastic  Petri  nets  through  model  Transformation, 
AADL:  Architecture  Analysis  &  Design  Language 

FMEA:  Failure  Mode  and  Effects  Analysis 
FMEA/CA:  FMEA /Criticality  Analysis 

OSATE:  Open  Source  AADL  Tool  Environment  (Software  tool  integrated  into  Eclipse) 

SAE:  Society  of  Automotive  Engineers 
SAN:  Stochastic  Analysis  Network 

TOPCASED:  Toolkit  In  OPen  source  for  Critical  Applications  &  SystEms  Development 
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